4. Mailbox Limits
As a seasoned
Exchange administrator you have most likely heard from someone that
"Storage is cheap, why must you put a limit on my mailbox rather than
just adding more disks?" For a number of really important reasons,
adding disk alone is not the answer. The primary reason is to meet
SLAs. Without established mailbox limits,
an SLA violation could occur in a number of ways. For instance, if none
of the 5,000 mailboxes on a mailbox server had limits imposed, any
single mailbox could consume all of the disks on a server in a matter
of minutes. Although this could happen as the result of a malicious
act, it can also be unintentional in a case where an Outlook rule or
outside service continues to send e-mail messages to a mailbox, causing
it to grow larger until the underlying storage fills up. With the
improved performance and faster server hardware, these sorts of actions
can happen in a matter of just a few minutes.
The other way mailbox
limits play into achieving an SLA and controlling the size of databases
has to do with achieving expected backup and recovery times. To recover
the data in a database within the agreed-upon SLA, the databases must
be under a specific size. For example, if you can restore 150 GB of
data from your backup solution in three hours, and you have a four-hour
SLA to restore the data, you do not want to allow the database to grow
larger than 150 GB; otherwise, anytime a restore is required, the SLA
will be violated. The easiest way to implement and maintain control
over the size of the databases is to establish limits on the mailboxes and thereby not allow them to cause the database to grow beyond the size that prevent SLAs from being met.
This really means there is no
hard and fast rule on how big mailboxes should be—just that a maximum
size should be set. The best practice is to set a limit that in
aggregate is less than the available disk space. That way if all
mailboxes on the server reach the limit, the server will still have
space to continue operating. That said, this may not be completely
feasible, nor is it probable that all users will use their entire quota
at the same time, unless there is malicious intent. In this case it is
important to weigh the risks and costs involved.
|
Thierry Demorre
Senior Director, Infrastructure Services Line, Avanade Inc.
At some point during the design
phase of a new Exchange environment comes the decision of the mailbox
size. This decision prompts questions like "How much should we
allocate?", "Should all mailboxes have the same limits and retention
policies?", and "Should users have mailbox sizes that coincide with
their job function, and if so how would that be determined?" It is
appropriate to answer all of these questions before doing everything
else, and that requires knowing the big picture of where you are
deploying Exchange. To do this you will need to interview the legal
team to understand what the retention policy needs to be. For example,
if the legal team wants everything older than six months purged and
inaccessible, that will need to be the starting point for evaluating
the mailbox size.
On the other hand, if no
restrictions are to be put in place, evaluation of the Exchange Server
2010 online archive or third-party archiving solution should be done
along with determining the potential impact to the configuration and
performance of implementing the archiving solution. Most of these
archiving companies have been singing the praises of their products,
and especially how stubbing items being archived was a way to save
space in your online mailbox. As a best practice, however, using any
form of stubbing is a bad approach. This has always been a limiting
factor in Outlook—performance can degrade when the number of items
grows out of control. While Outlook 2007 SP2 and Outlook 2010 introduce
technology improvements for many more items in each folder, as well as
larger mailboxes, keeping the environment under control is of paramount
importance to keep the performance optimal for the end user. It is
important to archive smart, rather than retaining data just for the
sake of retention.
The appropriate course is to
evaluate this question as any other critical aspect of your design. It
would be wise to interview representatives from a number of user groups
and obtain their requirements. It might be that one group only cares
about the last three weeks' worth of e-mail, and another group that has
a completely different or conflicting requirement. It would also be
good to obtain some less subjective data, perhaps by creating a trend
of current mailbox
sizes. Because older versions of Outlook may not perform properly with
large mailboxes or will not provide access to new features available in
Exchange Server 2010, it is important to identify the client software
that will be used. I know of companies that will deploy Exchange Server
2010, and then continue to use Microsoft Office Outlook 2003 to connect
to their new messaging system.
So, how do you answer the question,
"Can I create a 1-TB mailbox?" It is true that Exchange Server 2010
will certainly allow this. However, the reciprocal question would be,
"Will you use it?" If you fill that mailbox with messages with an
average size of 50 KB, that is approximately 24.5 million messages!
|
5. Configuring Deleted Item Recovery Quotas
Configuring the deleted
item recovery setting needs to be done after the business needs are
captured and understood. However, a couple of settings should be
configured to ensure that malicious users cannot cause Denial
of Service attacks by placing large amounts of data into the dumpster
and running the server out of space. To do this the RecoverableItemsQuota and RecoverableItemsWarningQuota
settings should be set per database. However, the settings can also be
done per mailbox. These settings are similar to mailbox quotas except
that they apply to items in the dumpster:
RecoverableItemsQuota
The default limit is 30 GB; however, this can be set as needed. When
the limit is reached all soft deletes will fail and an event log entry
will be made the first time it occurs and once daily if the condition
continues.
RecoverableItemsWarningQuota
The default limit is 20 GB; however, this can be set as needed. When
the limit is reached, an event log alert will be made and will continue
once daily afterward if the condition continues. The oldest items in
the dumpster will be deleted to make room for new dumpster data.
6. Poison Mailbox Detection and Correction
Exchange Server
introduced poison message detection, placing messages that cause issues
with the transport service in a queue and allowing the transport
service to continue processing other messages. Exchange Server 2010
applies this same concept to mailboxes. In some cases a single mailbox
with corrupt data caused the Exchange Store to crash or even to crash
repeatedly. With poison mailbox detection the Exchange information store is able to detect and then isolate the poison mailboxes.
A mailbox will be tagged as a potential threat if:
When a mailbox meets
either of these criteria, an entry in the registry is made for the
database along with the number of times the problem has occurred.
Storing this information in the registry allows this information to be
replicated to other servers in the DAG by the Windows Cluster service.
This allows this information to be preserved during a failover. This
information is stored in the following locations in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\Crash Count
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server
Name>\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox
GUID}\\LastCrashTime
The default settings can be
adjusted for how many crashes lead to quarantining a mailbox as well as
how long a mailbox should stay quarantined are stored. You can adjust
these settings by modifying the following registry keys:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server
Name>\Private-{Database
GUID}\QuarantinedMailboxes\MailboxQuarantineCrashThreshold The default
setting for this key is three crashes.
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server
Name>\Private-{Database
GUID}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds The
default setting for this is 21,600 or six hours.
The Exchange information store
will also keep information on when the mailbox was flagged as a poison
mailbox. When a database is brought online and periodically thereafter,
the information store reads the time that the mailboxes were identified
as potential threats. If the mailbox was quarantined more than two
hours prior, the registry key for the mailbox will be wiped out.
After a mailbox is flagged
and quarantined, no access is allowed to the mailbox by any end users
or any of the Exchange processes. If the mailbox hasn't caused any
crashes in the last two hours and is not quarantined, the registry path
for the mailbox will be cleaned up by the information store. If a
mailbox has been quarantined for longer than the MailboxQuarantineDurationInSeconds
since the last time it caused a crash, it will automatically be removed
from quarantine. If the problematic mailbox has been fixed, the mailbox
can also be removed from quarantine manually by deleting the registry
key and then remounting the affected database.
To be sure to keep ahead of
any impending issues, you should monitor these registry keys to ensure
that there is not a systemic problem causing multiple mailboxes and
databases to become corrupt. This will also allow administrators to
track down any issues and fix them.
